1. Field of Invention
The present invention relates generally to computing systems which utilize Enterprise JavaBeans. More particularly, the present invention relates to timers for state machines which are implemented as Enterprise JavaBeans.
2. Description of the Related Art
The Java 2 Platform, Enterprise Edition (J2EE) is an industry-standard general purpose platform for the development of enterprise business applications. Enterprise business applications include applications for purchase order management or transactions processing. As a part of J2EE, application logic may be implemented using the Enterprise JavaBeans (EJB) component model which provides application development tools for application developers.
In general, an EJB component model is a component architecture for the development and the deployment of object-oriented, distributed, enterprise-level applications. An application developed using the EJB component model is scalable and transactional, and is typically portable across multiple platforms, which enables an EJB component to effectively be xe2x80x9cwritten oncexe2x80x9d and xe2x80x9cused substantially anywhere.xe2x80x9d That is, EJB components may also be used by multiple applications, i.e., EJB components may be shared or reused. As will be understood by those skilled in the art, the EJB component model enables application development to be simplified due, at least in part, to the fact that typically difficult programming problems are implemented by an EJB container, and not the application.
Some applications utilize state machines, or are designed to use the concept of a state machine in their implementation, and have generally not been developed using J2EE. Specifically, there has been a perceived mismatch between the J2EE programming model and requirements associated with state machines. A state machine may be considered to be a behavior that specifies the sequences of states that an object goes through during its lifetime in response to events, in addition to its responses to those events. A state of an object is a condition or a situation during the lifetime of an object which satisfies some condition, performs some activity, or waits for one or more events. An event is the specification of an occurrence that has a location in time or space that may trigger a state transition associated with the object.
Applications which use state machines include telecommunications, or xe2x80x9ctelecom,xe2x80x9d applications. Typically, within telecom applications, each telecom vendor uses its own proprietary technique to implement state machines. A state machine which may be used in a telecom application is shown in FIG. 1. FIG. 1 illustrates a state machine that is associated with a base station controller in a cellular telecom network. A cellular network 100 includes a mobile station (MS) 102, a base transmittal station (BTS) 104, a base station controller 106, and a mobile switching center 108. MS 102 may be substantially any device which is suitable for use within cellular network 100, e.g., MS 102 may be a cellular telephone. BTS 104 generally includes radio equipment that controls a cell within cellular network 100. BSC 106 is a telecom application that provides the implementation of call control logic, such as the logic for the setup and the termination of connections. MSC 108 includes telecom equipment that handles the traffic, e.g., voice traffic, of established connections.
BSC 106 or, more specifically, the telecom application associated with BSC 106, is generally implemented as a connection state machine 114 or a set of connection state machines. Connection state machine 114 implements the protocol for the setup of, and the termination of, connections between MS 102 and MSC 108.
The connection setup and termination protocol generally begins when MS 104 requests a connection by sending a RequestConnection event 118 to BTS 104. BTS 104 then sends RequestConnection event 118xe2x80x2 to BSC 106, which causes a connection state machine object to be created within BSC 106 or, more specifically, the telecom application within BSC 106.
Upon creating a connection state machine object, connection state machine 114 sends an AllocateResources event 122 to MSC 108 to essentially request that MSC 108 allocate resources for voice traffic. Once MSC 108 has allocated the resources as requested, MSC 108 generates a ResourcesAllocated event 124 which is sent to BSC 106 and indicates that resources have been allocated.
After receiving ResourcesAllocated event 124 from MSC 108, BSC 106 or, more specifically, connection state machine 114 sends a ConnectionEstablished event 128 to BTS 104 indicating that a connection has been established in response to a request from MS 102. In response to receiving ConnectionEstablished event 128, BTS 104 sends ConnectionEstablished event 128xe2x80x2 to MS 102 such that MS 102 is notified of an established connection.
When MS 102 no longer needs a connection, i.e., once MS 104 has completed its use of a connection, MS 102 may xe2x80x9chang upxe2x80x9d on the connection. When MS 104 hangs up on the connection, MS 102 sends a TerminateConnection event 132 to BTS 104. Upon receipt of TerminateConnection event 132 by BTS 104, BTS 104 sends TerminateConnection event 132xe2x80x2 to BSC 106 and, hence, connection state machine 114. Connection state machine 114, in turn, sends a DeallocateResources event 136 to MSC 108, which deallocates voice traffic resources, and sends a ResourcesDeallocated event 140 to BSC 106. It should be appreciated that once BSC 106 receives ResourcesDeallocated event 140, BSC 114 deletes the state machine object it allocated in response to RequestConnection event 118xe2x80x2.
FIG. 2 is a state chart diagram which illustrates an algorithm of a connection state machine, e.g., state machine 114 of FIG. 1. That is, FIG. 2 is an algorithmic representation of an overall connection process associated with cellular network 100 of FIG. 1. A process of implementing a connection begins at step 202 in which a connection is requested. The request for a connection results in the creation of a connection state machine object. Once a connection is requested, allocation of resources is effectively requested in step 202, and resources for the connection are allocated in step 204, e.g., for voice traffic in a cellular telecommunications network. When resources are allocated, voice traffic is allowed to xe2x80x9cflowxe2x80x9d over the cellular telecommunications network. Once the connection is no longer needed, the connection is terminated in step 210, and the deallocation of resources allocated to the connection is commenced in step 212. After resources are deallocated in step 214, the process of implementing a connection concludes.
In the course of allocating resources, timeouts may occur, as will be appreciated by those skilled in the art. When timeouts occur during the allocation of resources or the deallocation of resources, cleanups occur, as for example in steps 216 and 218. Once cleanups have occurred, the process of implementing a connection is terminated.
A state machine generally uses timers to bound the time interval in which the state machine exists in a particular state. Typically, a state machine enters a state with an expectation that it will receive an external event within a specified time interval. To ensure that a state machine does not wait for too prolonged a time for the external event to occur, the state machine may create a timer that is in tact over the course of the specified time interval. When an external event occurs prior to the expiration of the timer, then the state machine cancels the timer. Alternatively, when an external event does not occur prior to the expiration of the timer, i.e., when the timer expires, the state machine is signaled. Typically, the state machine is signaled to proceed to a new state.
A timer service typically provides a timer creation method that uses a time duration, expiration callback, and identifying data as input and returns a timer cancellation token or callback as output. The timer service begins counting down the time duration immediately after the timer is created. A timer may generally be cancelled by either calling a services cancellation method with the cancellation token or, alternatively, by calling its associated cancellation callback method. If the timer duration expires before it is cancelled, the service signals the expiration by calling its expiration callback with identifying data from the timer. Once the timer is either cancelled or expires, the timer ceases to exist.
A timer service is crucial to a state machine since timer services are used by a state machine to provide a limit or bound for a time interval in which the state machine exists in a particular state, as previously mentioned. Therefore, what is desired is a method for implementing a state machine as an enterprise bean and for implementing a reliable timer service for use with such an enterprise bean.
The present invention relates to implementing state machines as enterprise beans with reliable or transactional timers on an enterprise platform. A reliable timer often implies that the creation of a timer is part of an atomic transaction and generally only occurs if all other work in the transaction has been committed. According to one aspect of the present invention, a state machine is arranged to be used within a computing system that supports an enterprise platform. The state machine includes an entity object, a home interface associated with the entity object, and a remote interface associated with the entity object. The home interface is arranged to create, find, and remove entity objects, while the remote interface is arranged to drive the state machine. The entity object is arranged to be deployed in a bean container, which includes a timer. In addition to including a timer, the bean container is arranged to invoke the entity object using the remote. In one embodiment, the timer is transactional.
These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings.
The invention may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:
FIG. 1 is a diagrammatic representation of a state machine associated with a telecommunications application.
FIG. 2 is a state chart diagram which illustrates an algorithm of a connection state machine, e.g., state machine 114 of FIG. 1.
FIG. 3 is a diagrammatic representation of a JavaBean component to which deployed in an Enterprise JavaBean container in accordance with an embodiment of the present invention.
FIG. 4 is a diagrammatic representation of an Enterprise JavaBean container, e.g., container 310 of FIG. 3, which includes a timer object in accordance with an embodiment of the present invention.
FIG. 5 is a process flow diagram which illustrates the steps associated with the processing of a timer in accordance with an embodiment of the present invention.
FIG. 6 is a diagrammatic representation of a typical, general-purpose computer system suitable for implementing the present invention.